For example mobile telecommunication networks are developed rapidly and new network elements are installed in the networks of network operators and old network elements are updated to provide new services. Unfortunately international standards are not accurate enough, however, wherefore there are differences in management interfaces of network elements between both different manufacturers and different versions. Especially with the new free competition in the field of telecommunications it is more important for the network operators to rapidly introduce the new services enabled by the network. In order to enable the use of the services, the network management system must first be modified to support the new management interface versions and the network elements of new manufacturers. The implementation of these modifications is at present slow, which delays the introduction of both new services and new types of apparatuses.
A model of a network management system is shown in FIG. 1. Network operators who work in operation centres OC (or OMC=operation and maintenance centre) use network management workstations WS that are connected to a separate workstation network WSN, such as Ethernet. The management system is typically decentralized into several computers of the workstation network, some of the computers comprising a database DB containing the data required for managing the network. The management system is connected via an interface defined in the international standards, for example, to a mobile telecommunication network MN having network elements that are denoted by NE. These network elements could include, for example, a mobile services switching centre MSC, a base station controller BSC, a base station BTS and a mobile station MS. The connection to the network to be managed takes place via a datacommunications network DCN. This kind of datacommunications networks are disclosed e.g. in CCITT Recommendation M.3010, Geneva, 1992, Principles for a Telecommunications Management Network, International Telecommunication Union (ITU), especially pages 1-6, the content of which is incorporated hereinto by reference. Logically, then there are two networks: (a) the network used to provide clients with services (e.g. a mobile network MN) and (b) the network used to maintain the network providing services.
When network operators manage large networks, they often divide the networks into parts that are managed by certain individuals in the local management centre. The network operators also need centralized management centres (e.g. at night one centralized management centre may manage several parts of the network). These local and centralized management centres have their own installations of a data system that are configured specifically to manage a part/parts of the network (in order to make the data system as effective as possible). Performing these configurations is rather difficult and time-consuming, however.
Besides wanting the freedom to assemble their network from the network elements of different equipment suppliers, the network operators also want to update the software of the network elements freely. For example, the operators want to update a part of the network at a certain moment and not to update the rest of the network. The operators therefore want to use new versions in a restricted part of the network for a certain trial period, for example six months, whereafter the rest of the network could be updated if the new versions are found suitable.
At the moment, the manufacturers of network management systems cannot give the network operator this freedom to update the software of the network elements due to the poor ability of the systems to process a multi-version and multi-supplier environment. In practice the network operator then has two choices: either to update the entire network in a short time or to suffer from defects in the functionality of the network management software.
The above-described problem has a known solution, i.e. a design pattern known in the literature by the name abstract factory. The arrangement is implemented in the following manner:
1) A separate interface is defined for the changing part of the application (e.g. a network management application). In a way this interface is a protocol definition that describes how the unchanging part and the changing part communicate with each other.
2) The changing parts of the application are implemented in such a way that they comply with the interface definitions according to item 1).
3) The application is provided with a so-called abstract factory from which the unchanging part of the application requests for the implementation of the changing part.
FIG. 2 is a functional block diagram illustrating a network management system based on the aforementioned known arrangement. The system consists of a controlling part 11 (comprising the network management software and hardware located in the operation centre) and of the network 12 to be managed and of a management interface 13 located between them. The controlling part and the network to be managed communicate with each other via the management interface. The network to be managed comprises several network elements; the figure shows two different network elements denoted with A and B. Network element A may be for example a base station controller and network element B may be a mobile services switching centre.
Network management software is typically implemented in such a way that it consists of an unchanging part 14 that remains the same in change situations and of several changing parts that model such parts of the network to be managed (e.g. network elements) that can change.
The network management software (the controlling part 11) therefore comprises a part A' that corresponds to network element A, that corresponds to the part of the software that models within the controlling part network element A of the network to be managed, and that communicates with the physical network element A. Correspondingly, the network management software comprises a part B' that corresponds to network element B, that models in the network management software the physical network element B and that communicates with the physical network element B (in the figure the communication is illustrated with arrows passing through the management interface 13). These changing parts contained in the controlling part are denoted with a common reference MO.
In the aforementioned solution, the network management software comprises a special abstract factory 15 from which the unchanging part of the software requests for the (concrete) implementations of the changing parts. This is illustrated with an arrow denoted by GetA' (). After it has obtained the reference data of the changing part, the unchanging part of the software makes the part (A') perform the desired functions. This is illustrated with an arrow denoted by Function1().
The abstract factory arrangement is described in greater detail in Design Patterns, Elements of Reusable Object-Oriented Software by Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (Addison-Wesley 1995, ISBN 0-201-63361-2, pp. 87-106) that provides a more detailed description, if required.
The above-described known arrangement has drawbacks, however, that are related for example to a multi-supplier environment in the case of a network management system.
FIGS. 3a and 3b illustrate how a network management system implemented with the abstract factory model is modified to the management of networks supplied by different manufacturers. FIG. 3a illustrates the management of a network supplied by manufacturer1 and FIG. 3b illustrates the management of a network provided by manufacturer2. The network elements include in this example a base station BTS and a mobile services switching centre MSC. No problems have occurred yet in the cases shown in FIGS. 3a and 3b, since there is only one concrete implementation of one changing part (a base station or a mobile services switching centre).
The lack of problems in the above-described examples is due to the fact that the effectiveness of the abstract factory arrangement is based on an assumption that one environment is comprised of only one implementation of one changing part. However, this assumption does not hold true in practice in the network management environment, since the network of the network operator may comprise different versions of one network element (e.g. a base station) provided by several different suppliers. The abstract factory model solves the problem of managing several implementations by multiplying the abstract factory parts of the system. FIG. 4 illustrates a system where the managed network comprises network elements supplied both by manufacturer1 and by manufacturer2. FIG. 5 illustrates a system where the managed network comprises different versions of the same network element (a BTS or an MSC) provided by the same manufacturer. For the sake of clarity, the figures do not show the communication passing through the management interface. This communication corresponds entirely to what is shown in FIG. 2: corresponding parts communicate with each other.
According to this known arrangement, several abstract factory parts (in the FIGS. 15a to 15d) are added to the system if there are several different implementations of one changing part. However, such an arrangement cannot be used to eliminate the aforementioned drawbacks, since it breaks the division of software into an unchanging and changing part (which increases the time used for implementing the change). For example if the network operator adds to the network a base station supplied by manufacturer3, the unchanging part of the software must be changed since it must start using the abstract factory specialized in the network elements of manufacturer3.